DEPRECATION
natPortal no longer uses Appwrite as a backend
Executive Summary
The revision and the continued operation of natPortal requires that a well-organized database stores data, an API performs operations on that data, and a CMS provides non-technical persons with the means to manually manage and view that data. The natPortal team presently evaluates options for a database, CMS, and a backend to serve that data, thus composing the whole of the natPortal backend.
This document compares the following CMS/backends:
- Appwrite
- Supabase
- Pocketbase
- Firebase
- Payload
- Strapi
for the purposes of replacing Strapi on the current deployment of natPortal. This document also serves as a record of the natPortal team’s design process and underlying rationale.
List of Figures
List of Tables
Self-host feasibility comparison
List of Acronyms/Abbreviations
| CMS | Content Management System |
| API | Application Programming Interface |
| NAT | Network for Applied Technology |
| DBMS | Database Management System |
| SQL | Structured Query Language |
| BaaS | Backend as a Service |
| GUI | Graphical User Interface |
| ACID | Atomicity, Consistency, Isolation, Durability |
1. Requirements
The CMS allows NAT’s staff to easily modify and view data in the database without the limitations of using the public front-end, or the complexity of lower-level database queries.
The backend allows the dependent services to access and perform CRUD operations on data in the database. Data returned by the backend may include data which is configured through the CMS.
Most CMS are also backends which serve the data registered in the CMS’ database, fulfilling both the role of a CMS and an API on the database. Likewise, most backends, especially ready-to-use BaaS solutions, have some interface in which authorized users may view and modify the database, without knowledge of the underlying database’s query syntax or the backend’s API.
| Layperson interaction | Non-technical persons must be capable of interacting with the database (no SQL queries) |
| Dashboard security | Persons using the administrator interface must authorize with credentials |
| API security | Public access to the CMS’ API should only be possible with authentication using an API key |
| DB security | The CMS must not allow unauthorized users to access data in the database |
| ACID compliance | Software considered must be compatible with a database system which provides support for ACID transactions, with preference for SQL-compatibility with PostgresQL |
| Open-source | Software considered must allow the study and modification of its underlying mechanisms and configuration |
| Self-hosting | Software considered must allow NAT to run the software on NAT-managed servers, including NAT's current Azure VM, with no features restricted to the software when remote-hosted as a service |
Table 1. List of requirements for the CMS/Backend.
Within this document, we consider solutions which require minimal developer setup. A custom backend/CMS fulfills all requirements; however, it requires months of development to fulfill that scope. While considering the contents of the document, the reader is advised to compare each solution to an in-house solution, from scratch, and consider the work required to address the solution’s shortcomings therein.
2. Content Management System/Backend
We compare the CMS/backend ready-to-use solutions/frameworks considered in the following table:
| Supabase | Appwrite | Pocketbase | Firebase | Payload | Strapi | |
|---|---|---|---|---|---|---|
| Open-source | ||||||
| No self-host limitations |
Table 2. Table comparing the open-source and self-hosted limitations of each all-in-one CMS option.
Henceforth, we only consider Supabase, Pocketbase, Appwrite, and Payload, due to the self-hosted limitations presented by Firebase and Strapi.
2.1 Functionality
Supabase, Pocketbase, and Appwrite are marketed as a BaaS. All three have been dubbed “a open-source self-hosted alternative to Firebase”. As such, they are not primarily CMS solutions, but all-in-one backend solutions which also abstract low-level manual modification of underlying data from an administrator dashboard. In addition, Supabase and Pocketbase allow defining SQL queries on the underlying database, which Strapi, Payload, and Appwrite lack and prefer to abstract away, allowing compatibility with a wider range of databases.
In contrast, Strapi is marketed as a headless CMS; as such, Strapi allows a much higher-level interface to modify the underlying data. It should be noted that in the current usage of Strapi, natPortal does not leverage these higher-level interfaces, but simply abstracts on low-level database queries like any other backend.
Payload is also marketed as a headless CMS, as well as a “full-stack app framework”. Like Strapi, Payload allows a much higher-level interface to query the database, but performs them more directly, rather than using the CMS as a proxy to reauthorize authorized requests from the web app. Both Strapi and Payload provide comparisons between their two products[3] [4].
Due to the distinct functionality between CMS solutions and BaaS solutions, some developers opt to use both a CMS and a BaaS[5]. However, both Strapi and Payload have evolved into a backend role in addition to a CMS.
To allow all of NAT’s services to authenticate under one authentication provider, natPortal will depend on Zitadel, a self-hosted authentication provider. However, all considered solutions provide their own authentication solutions.
| Supabase | Appwrite | Pocketbase | Payload | Strapi | |
|---|---|---|---|---|---|
| User authentication (Zitadel) | Requires custom work, no dashboard. | Simple integration | Simple integration | Simple integration | Simple integration |
| Database storage | |||||
| File storage | |||||
| Secure public API | |||||
| Turnkey solution* | Requires developer expertise | ||||
| Query-level database interaction* | |||||
| GUI database interaction | Requires setup | ||||
| Component-level content management* | Extremely customizable. Requires setup | Requires setup | |||
| Administrator dashboard | Extremely customizable | ||||
| ORM support | With Prisma | Unnecessary with SQLite | Built-in | With Prisma | |
| Vector support | Built-in with pgvector | Requires connection with separate database Pinecone, Upstash or otherwise custom setup | Requires plugin or custom integration | Built-in | Requires custom integration |
Table 3. Table comparing the provided functions of each CMS/BaaS solution
2.2 Maturity/Active development
All options considered are actively maintained and developed by the open-source community as well as employees of their respective companies.
Payload, Appwrite, and Supabase are much more mature projects than Pocketbase. However, Pocketbase is significantly more efficient and modern. With time, Pocketbase, with overwhelming open-source support, may become the better choice. However, Pocketbase has not published any real-world large-scale uses.
Both Appwrite and Supabase operate as BaaS (backend as a service) providers, offering managed hosting for enterprise as an alternative to self-hosting. Both Appwrite and Supabase currently enjoy active maintenance on an open-source codebase.
Strapi has the greatest maturity out of all considered solutions.
2.3 Databases
natPortal currently uses a Postgres database, with Strapi serving as both a backend and a CMS. Strapi is also compatible with MariaDB, SQLite, and MySQL.
Appwrite uses its own MariaDB instance. Appwrite is only compatible with MariaDB[1] and is therefore incompatible with Postgres[2]. Appwrite provides an adapter to migrate databases from other BaaS solutions, such as Supabase and Neon. MariaDB allows for vector storage and search with comparable performance to pgvector. Appwrite also provides an adapter for compatibility with vector databases such as Pinecone and Upstash.
Pocketbase uses a SQLite database. We raise concerns on the use of Pocketbase regarding performance with many simultaneous transactions at scale.
Supabase uses a Postgres database, as well as providing vector search APIs using a built-in pgvector plugin.
Payload allows the choice between MongoDB, SQLite, or Postgres.
Document History and Authentication
Reviewers
| Name | Role | Signature | Date |
|---|---|---|---|
Record of Document Changes
| Version | Date | Author(s) | Description of Changes |
|---|---|---|---|
References
[1] GitHub feature request: Native Postgres support. https://github.com/appwrite/appwrite/issues/2541
[2] Appwrite’s RFC 016 for database adapters. https://github.com/appwrite/rfc/blob/main/016-database-adapters.md
[3] Comparison of Strapi and Payload. From Strapi. https://strapi.io/headless-cms/comparison/strapi-vs-payload
[4] Comparison of Strapi and Payload. From Payload. https://payloadcms.com/compare/strapi
[5] Using Payload as a CMS, Supabase bucket as storage https://payloadcms.com/posts/guides/setting-up-payload-with-supabase-for-your-nextjs-app-a-step-by-step-guide